使用 Clash 时，代理连接正常、出口 IP 符合预期，只能说明部分网络请求已经经过代理。DNS 查询是否沿着预期路径发送，还需要单独确认。
这也是 DNS 防泄漏配置的重点：明确哪些查询由客户端处理，哪些交给远端节点解析，以及查询经过什么连接抵达解析服务。
本文面向采用 Mihomo 内核的桌面客户端，从解析路径出发，介绍一套可检查、可验证的配置方法。使用配置示例前，先确认客户端所用内核支持相应字段。
01 识别两条不同的路径
DNS 泄漏通常发生在流量路径分离的地方。 应用访问网站前，可能先通过系统 DNS 查询域名。如果网页连接进入代理，而查询仍发送给本地路由器或运营商，两类请求就走了不同的路径。
普通 DNS 查询通常以明文传输，沿途网络可以观察其中的域名。这类查询主要暴露“访问了哪个域名”，通常不包含 HTTPS 网页的完整路径和正文。Cloudflare：DNS 加密说明
是否构成泄漏，还取决于预期策略。例如，明确安排公司内网域名由内部 DNS 解析，是正常的分流设计；要求经过代理的查询意外发送给运营商，才是需要处理的问题。
02 接管、加密和出口分别负责什么
完整的 DNS 策略需要同时考虑接管、加密和出口。
| 配置层面 | 需要解决的问题 |
|---|---|
| DNS 接管 | 应用发出的查询是否进入 Mihomo |
| 查询加密 | Mihomo 与上游 DNS 之间是否使用 DoH 或 DoT |
| 出口选择 | 上游 DNS 连接通过代理还是直接连接 |
只填写 1.1.1.1 这样的地址，通常只是更换 DNS 服务商。使用 DoH 或 DoT 才涉及传输加密，而加密连接本身仍有直连和代理两种路径。Cloudflare：加密 DNS
因此，配置时应当明确指定解析服务和出口，并检查应用有没有绕过这套设置。
03 建立可检查的解析路径
可以先建立一条简单、明确的解析路径，再逐步增加分流。 以下示例使用 TUN 接管流量，将普通 DNS 查询交给 Mihomo，并让本机需要发出的上游查询经过指定代理组。
代理节点自身的域名使用独立解析服务处理。这样，在代理尚未建立时，客户端就能取得节点地址，避免解析过程反过来依赖尚未连通的代理。
如果还不清楚 TUN 与系统代理分别接管什么，可以先看系统代理与 TUN 的区别，再调整下面的配置。
实际操作前，先备份当前配置。下面只包含 TUN 与 DNS 部分，需要通过客户端提供的配置编辑或覆写功能整合到现有配置中。
先备份，确认内核支持字段及代理组名称，再使用客户端的覆写或合并功能。不要覆盖节点和分流规则。
tun:
enable: true
auto-route: true
auto-detect-interface: true
# 需要支持该字段的近期 Mihomo 内核
dns-mode: native
dns-hijack:
- any:53
- tcp://any:53
strict-route: true
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
# 解析 DNS 服务自身的域名
default-nameserver:
- tls://223.5.5.5
# 独立解析代理节点域名
proxy-server-nameserver:
- "tls://223.5.5.5#DIRECT"
# 替换为配置中真实存在的代理组名称
nameserver:
- "https://cloudflare-dns.com/dns-query#节点选择"
示例中的 #节点选择 指定上游 DNS 连接使用该代理组。应用前，需要将它替换成实际名称，并确认该组最终选中代理节点，也不会在失败时回退到 DIRECT。Mihomo 支持在 DNS 地址后指定代理或接口；通过代理查询时，应同时配置独立的节点域名解析服务。Mihomo DNS 配置
这里选用阿里 DNS 的 DoT 地址作为引导解析示例，该地址也出现在 Mihomo 的官方配置中。它是否适合当前网络，仍需实际验证。Mihomo 配置示例
引导解析直接连接指定服务，意味着该服务可以看到节点域名等引导查询。这是一项明确的信任选择，应当与网站域名的解析路径分别理解。
dns-mode: native 用于将系统 DNS 指向 TUN；dns-hijack 则将匹配的 DNS 连接导入内置解析模块。系统 DNS 仍指向局域网路由器时，单靠劫持配置存在平台限制。如果内核不支持 dns-mode，应先核对客户端对应的系统 DNS 接管功能。Mihomo TUN 配置
04 检查最终生效配置
配置合并之后，还需要检查最终生效的内容。 订阅原有的 nameserver-policy、fallback 和 direct-nameserver 都可能影响解析路径。新增一个 nameserver，并不会自动清除已有策略。
初次排查时，保持路径简单更容易定位问题。公司内网、NAS 或自定义局域网域名，则应按需保留专门的解析规则；公共 DNS 通常无法解析这些内部名称。
05 检查浏览器独立 DNS
浏览器的安全 DNS 会增加一条需要检查的路径。 Chrome 等浏览器可以自行使用 DoH，此时查询可能绕过 Mihomo 的 DNS 模块，但 DoH 连接仍可能经过 TUN 和代理。
排查时，可以记录浏览器原设置，临时关闭其独立的安全 DNS，让查询先统一进入系统解析路径。确认接管正常后，再决定是否恢复独立解析，并验证对应连接的出口。
Chrome 的自动模式在安全查询失败时可能使用未加密查询；选择自定义提供商时，回退行为有所不同。因此，验证时也应记录浏览器采用了哪一种模式。Chrome 官方说明
06 分三层验证
验证应同时观察解析结果和传输路径。 DNS 检测网站适合发现异常，但无法独自覆盖整台设备的所有流量。
可以先访问 DNSLeakTest，执行 Extended test。测试会让浏览器查询一组域名，再观察哪些 DNS 服务器参与解析。同一家服务商可能使用多个服务器，所以结果中的 IP 数量不能直接作为泄漏数量。DNSLeakTest 测试原理
阅读结果时，可以参考下面的判断方式：
| 检测结果 | 如何理解 |
|---|---|
| 出现预期的解析服务商 | 与策略相符，继续确认连接出口 |
| 出现未预期的本地运营商 | 检查系统 DNS、浏览器设置及接管范围 |
| DNS 所在国家与节点不同 | 地理位置差异本身不足以判定泄漏 |
| 出现远端节点使用的解析服务 | 核对是否由节点完成域名解析 |
这里需要特别注意 Fake-IP 模式。Mihomo 可以将目标域名交给远端代理，由远端完成解析。因此，即使本机配置了 Cloudflare，检测结果也未必只出现 Cloudflare；本机 nameserver 无法统一规定远端节点的解析服务。Mihomo 解析流程
接着检查客户端的生效配置、代理组选择和可用的连接记录。缓存、日志级别及客户端展示方式都会影响观察结果，缺少某条日志只能说明当前没有看到相应记录。
如果需要更直接的证据，可以使用 Wireshark 抓取当前联网的 Wi-Fi 或以太网接口，并输入显示过滤器：
udp.port == 53 || tcp.port == 53
随后重新运行 DNS 检测，观察是否有测试域名的查询发往路由器或其他非预期服务器。该表达式用于筛选 TCP、UDP 的 53 端口流量。Wireshark 过滤器说明
抓包位置会影响结论。在 TUN 或回环接口中看到应用向 Mihomo 提交 DNS，可能属于正常接管过程；检查查询有没有离开预期路径，应重点观察实际联网的物理接口。
同时，53 端口没有查询，也只能说明这次观察中未发现相应流量。DoH 通常使用 443，DoT 通常使用 853，还需要结合目的地址和连接路径判断。Cloudflare：加密协议与端口
07 补齐 IPv6 与故障验证
IPv6 和故障状态需要分别检查。 dns.ipv6: false 控制 Mihomo DNS 对 AAAA 查询的响应，并没有关闭整台设备的 IPv6。如果当前网络支持 IPv6，应确认这部分流量同样符合接管和出口策略。Mihomo IPv6 DNS 设置
strict-route 不是独立的断线保护开关。它的作用也与平台相关。例如，Windows 下会通过防火墙规则处理多网卡 DNS 泄漏问题。对于客户端退出、内核崩溃、休眠恢复等情况，是否仍能阻止意外直连，需要另行验证断线保护机制。Mihomo 严格路由说明
完成配置后，建议保留一份简短记录：客户端和内核版本、测试网络、预期 DNS 路径，以及实际观察结果。更换订阅、更新客户端或切换网络后，按照同样的方法复查，才能持续确认这套策略仍然有效。
尚未安装客户端，可先阅读Windows 入门教程。
